Skip to content

INWX: Add rules for TXT RRs containing double quotes and backslash #3544

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

eliheady
Copy link
Contributor

@eliheady eliheady commented Apr 24, 2025

INWX will not apply these RR changes and also does not error on the record content.

qoutes end up double-escaped. next preview:
TXT ("in\\\"side" ttl=300) -> ("in\"side" ttl=300)

odd-numbered backslashes get stripped. next preview:
TXT ("1backslash" ttl=300) -> ("1back\\slash" ttl=300)
TXT ("3back\\\\slash" ttl=300) -> ("3back\\\\\\slash" ttl=300)

Release changelog section

Some examples:

  • INWX: filter unsupported TXT RR content containing unbalanced quotes and backslashes

INWX will not apply these RR changes and also does not error on the record content.

qoutes end up double-escaped:

  TXT ("in\\\"side" ttl=300) -> ("in\"side" ttl=300)

odd-numbered backslashes get stripped:

  TXT ("1backslash" ttl=300) -> ("1back\\slash" ttl=300)
@eliheady eliheady changed the title Add rules for TXT RRs containing double quotes and backslash INWX: Add rules for TXT RRs containing double quotes and backslash Apr 24, 2025
@eliheady eliheady marked this pull request as ready for review June 5, 2025 00:55
@eliheady
Copy link
Contributor Author

eliheady commented Jun 5, 2025

@patschi what do you think about this? I am not sure blocking all of these records is the right thing, as it seems the characters are accepted if they are balanced in the records.

I can't work on it any further at the moment, but I was thinking a custom filter could be added to the INWX AuditRecords rules to check for the count of slashes and only block what INWX rejects. Then again, I think of what I've heard Tom say about avoiding too much error prevention and letting the provider APIs' errors inform users about problematic records (at least that's what I took from the comments that I can't find now lol)

@tlimoncelli
Copy link
Contributor

I agree that we should let the API do its job. In the real world, nobody actually needs to create records that are so weird. We shouldn't put too much effort into solving a problem that doesn't happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants